Wireless user terminals of today are commonly capable of using more than one access technology for connecting to different types of communication networks and access nodes, i.e. base stations. For example, a user terminal may be capable of using both packet-switched (PS) connections and circuit-switched (CS) connections for different communication services. A circuit-switched connection providing a “stable” bandwidth is deemed suitable for voice services requiring real-time communication, while a packet-switched connection with more fluctuating bandwidth can be used for less real-time oriented services such as Internet browsing, messaging, streaming and file downloadings.
When a user terminal is served by a packet-switched connection of a first network and at some point requires a circuit-switched connection of a second network, e.g. when a service is activated that is better suited for circuit-switched communication such as an incoming or outgoing voice call, the terminal needs to change from the packet-switched connection to a circuit-switched connection, commonly referred to as “CS Fallback”. In this case, the first network may be a Long Term Evolution (LTE) network and the second network may be a GSM or WCDMA network. This switch of connection can be executed in different ways, e.g. as specified in the Third Generation Partnership Project (3GPP).
One option is that the first network of the current packet-switched connection executes a regular handover of the terminal to a circuit-switched second network, which typically involves evaluation of a plurality of potential target cells in the new network, e.g. based on signal measurements, channel availability, etc., to determine which cell can best serve the terminal in the second network. However, a regular handover to a new network can be quite time-consuming due to the preparations required before the new circuit-switched connection is ready for use, and there is a substantial risk that the user(s) involved will find the wait frustrating and may even relinquish and end the service before any communication starts.
Another option is the somewhat faster process known as “release with redirect”, i.e. the first network simply releases the terminal from its currently used packet-switched connection and instructs the terminal to use a preselected circuit-switched connection in the second network. In practice, a base station in the first network sends a redirect message instructing the terminal to tune to a given frequency and/or channel of the preselected circuit-switched connection and try to establish the new connection with a nearby base station in the second network, commonly referred to as “attach”. The redirect message may also include various system information such as transmission schemes and communication parameters, sometimes referred to as Network Assisted Cell Change (NACC) information, for the terminal to use when attaching to the new connection.
However, since the new connection is preselected and has not been evaluated as suitable in this particular instance, there is a significant risk that the terminal for some reason fails to establish the new connection in the second network according to the redirect message, e.g. due to unfavorable radio conditions, no admission granted, or use of invalid system information.
A release-with-redirect process is illustrated in FIG. 1 where a wireless user terminal “T” currently using a first connection with “network 1”, receives a redirect message in a first action 1:1, directing the terminal to switch to a preselected second connection in “network 2”, e.g. after network 1 has detected a need for a new connection such as a CS connection for a forthcoming voice call. Terminal T then accordingly makes an attach attempt to a given base station in network 2, in an action 1:2, which for some reason fails.
Having failed the attachment to network 2, terminal T is forced to return to network 1 by sending a regular connection request to a base station in network 1, in an action 1:3, which may typically be the base station the terminal was connected to before attempting the new connection, or it may be another base station, e.g. if the terminal has moved to another location. At that point, the contacted base station in the first network will treat the terminal as any terminal requesting access, not being aware that the terminal has just failed to connect to the second network.
As a result, assuming that a circuit-switched connection is still needed, the base station in the first network may once again instruct the terminal to attempt the same preselected circuit-switched connection in another redirect message. In FIG. 1, network 1 thus sends the same redirect message once again after detecting that terminal T needs a new connection, in an action 1:4, i.e. directing the terminal to the same connection to network 2 as in action 1:1. The terminal will then most likely fail once again to attach, in an action 1:5, and so forth.
It is thus a problem that a terminal may repeatedly fail to attach to a new connection when needed in a predefined release-with-redirect process according to conventional solutions, and that any service requiring the new connection cannot be executed. Thus, the release-with-redirect process is predefined in the sense that the new connection is selected by default. A problem is also that the “blind” redirect process described above, i.e. without evaluation of the current actual connection conditions, is not very reliable to succeed and can cause significant delays and undue messaging over the air with the terminal. Further problems may persist in that the operator of either network cannot easily identify any problems and shortcomings in the release-with-direct process that may be the cause of the above attach failures.